Why is this necessary? The script is expected to be run with the root of the repository as the current directory; after all, other linting scripts work based on the same expectation. Given this, it should be enough to just use scripts as the scripting directory.

For robustness. All other linting scripts use git search, which is robust in that it searches from the repository base.

Apparently, git ls-files does not search from the repository base but from the current directory. For example, running the command git ls-files --exclude-standard --no-deleted --deduplicate '*.hs' (taken from scripts/lint-hlint.sh) when being in the scripts directory yields only generate-haddock-prologue.hs and generate-readme.hs.

So currently several, maybe most, of our scripts have to be run with the working directory being the repository base in order to function correctly. It would be good, of course, to change this, perhaps by adding a code snippet that just changes the working directory to the repository base right at the beginning, but, since this would be a change to be made to several scripts, it should be done in a different pull request.

I see no need to remove set -e, given that it is part of POSIX and probably widely supported.

See above.

You mean, it’s more robust to not rely on -e being available? I wouldn’t believe that. The -e option seems to be supported by basically any Unix shell: dash has it, bash has it, zsh has it, and a web search hasn’t revealed any shell that would not have it.

This isn’t necessary when leaving set -e in place.

See above.

This implements two, slightly different, ways of deciding on a sed executable:

1. gsed on Darwin, sed everywhere else
2. gsed when available, sed otherwise

I find solution 1 unnecessarily restrictive, since there may be other systems where GNU sed is available under the name gsed (I remember there being at least gmake on the Sun servers we had at university in the 1990ies 😄). Option 2 lifts that restriction, but it unconditionally uses sed whenever there is no gsed, even on Darwin, and thus risks picking a non-GNU sed. Best is probably to use gsed whenever available, use sed if gsed is unavailable but the system is GNU/Linux, and fail otherwise.

That would be a decent improvement, yes. As long as not having gsed on Darwin remains an error with an appropriate help message.

The current version in #683 certainly flags absence of gsed on macOS as an error. It doesn’t provide help on how to install gsed on macOS, since I believe that a Unix script shouldn’t provide assistance in installing certain software on particular operating systems and Homebrew should be so well known among developers using macOS that virtually all of them should know how to install gsed (and the remaining few ones could find out from the first hit of a corresponding web search 🙂).